1. The Field of the Invention
The present invention relates to systems and methods for compressing and decompressing Session Initiation Protocol (SIP) data structures. More specifically, the present invention relates to tokenized compression and decompression of SIP data structures to improve call setup times, particularly in wireless telephony devices that have relatively low processing speeds.
2. The Relevant Technology
The present invention generally relates to improving the performance of the Session Initiation Protocol, hereinafter referred to as SIP. The Session Initiation Protocol is a standard set forth by the Internet Engineering Task Force (IETF), the body responsible for administering and developing the mechanisms that comprise the Internet, and the details of the SIP protocol can be viewed in IETF Request for Comments 3261 (RFC 3261), which is incorporated herein by reference. SIP is an application-layer signaling protocol that can establish, manage and terminate interactive multimedia sessions over an Internet Protocol (IP) network. A session can be as simple as a two-way telephone call or as complex as a collaborative, multimedia conference season. Sessions include voice, video, chart, interactive games and virtual reality. The primary function of SIP is to help session originators deliver “invitations” to prospective session participants.
SIP originated in 1996 as a component of the “multicast backbone” or “Mbone”, an experimental multicast network that worked on top of the public Internet. It was used for distributing multimedia content, including seminars and meetings, and one of its key functions was to invite users to listen in on multimedia sessions on the Internet. In 1999, it was approved as an official standard by the IETF, and because of its fundamental design goals of scalability, extensibility, interoperability and flexibility, it soon rivaled competitive protocol H.232.
The H.323 protocol, while fairly widely adopted, has some significant liabilities, including lengthy call setup times. With H.323, a session is first established, and only then are the features and capabilities for that session negotiated, causing significantly longer call setup times than an average public switched telephone network (PSTN) call. In contrast, SIP uses less bandwidth because the messages to set up and tear down a session are fewer and smaller. For example, with SIP, the session is initiated and the features to be used during the session are negotiated all in one step. Although signaling using SIP is more flexible than its rival, H.323, utilizing SIP for mobile applications is still problematic because of the large size of SIP messages.
SIP was originally designed for high-speed bandwidth links. Thus, SIP messages can be large—from a few hundred bytes to several kilobytes—so its uses large amounts of bandwidth. More importantly, when SIP messages are run over a narrow-band link, such as a radio interface in a mobile telephony network, session initiation latencies become intolerably long. This is perceived by the user of the mobile service as a lengthy call setup time, which creates a poor user experience.
The large size of SIP messages and its resulting demand for bandwidth gave rise to the requirement for a compression mechanism for SIP. The IETF responded with Signaling Compression or “SigComp,” which is described in detail in RFC 3486 of the IETP. While SigComp adequately reduces the amount of bandwidth required for the transport of SIP messages, it has a number of significant limitations.
First, SigComp was designed to directly address reduction in bandwidth, and while this generally improves signaling latency, on certain classes of devices it also has negative impacts. In some cases it may even increase signaling latency, thereby actually increasing call setup time. SigComp uses complex compression algorithms to achieve bandwidth reduction, and is well suited for implementations which have significant CPU and power resources. In devices that are battery powered, the computation required to compress and decompress messages will create significant reductions in battery lifetime. In devices with slow CPU's, this computation takes a significant amount of time, and the time required to compress and decompress messages may actually cancel the latency improvements that are achieved by the reduction in message size. Both of these results make SigComp a poor choice for cellular telephones and similar mobile devices.
Second, SigComp is based on a technique known as stateful compression. In this model, each message contains references to data that was transmitted in previous messages. This model achieves high levels of bandwidth reduction, but it makes the system very sensitive to packet loss. If a packet is lost in transit, multiple effects are felt by the system. Besides failing to receive the original packet, the receiver no longer has the information from that packet, and any subsequent packets, even though properly received, must be discarded by the receiver. The receiver sends a signal to the transmitter indicating that synchronization has been lost, and all lost packets must be retransmitted. Thus, in SigComp, the loss of a single message in the network leads to the failure of two or more messages and significantly increased latencies while the transmitter and receiver are being resynchronized. Overall, these behaviors make SigComp a poor choice for networks that exhibit relatively high rates of packet loss.
Third, a key area of focus for wireless operators in Quality of Service (QOS). As part of an overall QOS program, it is important to have the ability to “sniff” or monitor the data traveling over the network. The ability to successfully monitor data on the network requires that the network information gathering device or sniffing device, such as a network analyzer or packet sniffer, maintain its own database for recording network activity and transforming it into actionable data at some later time. Because SigComp uses stateful compression, its use in this environment would require that the sniffing device maintain a database for each handset associated with the network being monitored. While this is possible, if adds a significant amount of complexity and expense to the QOS program at a time when wireless operators need to reduce expenses, simplify infrastructures, and drastically improve customers service. The ability to monitor the network is not only a QOS issue, but it is necessary for system debugging and for initial system qualification as well—all important processes that becomes much more difficult to perform in some environment using SigComp.
Therefore, what is needed is a method for increasing the efficiency of SIP signaling in a mobile IP network without increasing complexity, processing time or sacrificing battery life, such that call setup latencies are significantly reduced, bandwidth is used efficiently, debugging and monitoring are not adversely impacted, and customer satisfaction is improved.